Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3/3]: Implement Consumer on chainWatcher and resolvers #10

Open
wants to merge 64 commits into
base: master
Choose a base branch
from

Conversation

yyforyongyu
Copy link
Owner

No description provided.

Copy link

Pull reviewers stats

Stats of the last 30 days for lnd:

User Total reviews Time to review Total comments

@yyforyongyu yyforyongyu force-pushed the yy-blockbeat branch 3 times, most recently from f1648f6 to ba41ee4 Compare June 24, 2024 14:03
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch from 0034ee3 to ced95d8 Compare June 24, 2024 23:39
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch from ced95d8 to 3a163a1 Compare June 25, 2024 23:50
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch from 3a163a1 to fa69320 Compare June 27, 2024 01:29
@yyforyongyu yyforyongyu changed the title Implement Consumer on chainWatcher and resolvers [3/3]: Implement Consumer on chainWatcher and resolvers Jun 27, 2024
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch from fa69320 to 0cb50f1 Compare June 27, 2024 18:45
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch from 0cb50f1 to 8e7419f Compare June 27, 2024 19:59
@coveralls
Copy link

coveralls commented Jun 27, 2024

Pull Request Test Coverage Report for Build 9702817439

Details

  • 916 of 1194 (76.72%) changed or added relevant lines in 15 files are covered.
  • 51 unchanged lines in 15 files lost coverage.
  • Overall coverage increased (+0.02%) to 57.341%

Changes Missing Coverage Covered Lines Changed/Added Lines %
contractcourt/breach_resolver.go 10 11 90.91%
contractcourt/anchor_resolver.go 41 50 82.0%
contractcourt/channel_arbitrator.go 16 25 64.0%
contractcourt/chain_arbitrator.go 0 11 0.0%
contractcourt/htlc_outgoing_contest_resolver.go 13 24 54.17%
chainio/mocks.go 14 26 53.85%
contractcourt/htlc_incoming_contest_resolver.go 49 71 69.01%
lntest/harness_assertion.go 0 24 0.0%
chainio/blockbeat.go 0 32 0.0%
contractcourt/htlc_timeout_resolver.go 305 337 90.5%
Files with Coverage Reduction New Missed Lines %
contractcourt/anchor_resolver.go 1 78.03%
contractcourt/htlc_timeout_resolver.go 1 70.41%
watchtower/wtclient/queue.go 2 84.84%
invoices/invoiceregistry.go 2 82.26%
channeldb/graph.go 2 75.23%
lnwallet/chancloser/chancloser.go 2 81.13%
htlcswitch/link.go 2 69.57%
watchtower/wtdb/range_index.go 2 95.61%
htlcswitch/mock.go 2 75.25%
channeldb/channel.go 2 72.98%
Totals Coverage Status
Change from base Build 9702800783: 0.02%
Covered Lines: 92817
Relevant Lines: 161868

💛 - Coveralls

@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch 2 times, most recently from 77cf536 to da3a542 Compare June 27, 2024 22:48
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat branch 2 times, most recently from 040d363 to 651886f Compare June 29, 2024 02:18
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch from da3a542 to b4282fa Compare June 29, 2024 07:37
@coveralls
Copy link

coveralls commented Jun 29, 2024

Pull Request Test Coverage Report for Build 9722582087

Details

  • 982 of 1348 (72.85%) changed or added relevant lines in 17 files are covered.
  • 31 unchanged lines in 12 files lost coverage.
  • Overall coverage increased (+0.02%) to 57.325%

Changes Missing Coverage Covered Lines Changed/Added Lines %
contractcourt/breach_resolver.go 11 12 91.67%
lntest/harness_miner.go 0 2 0.0%
lntest/harness.go 0 3 0.0%
contractcourt/anchor_resolver.go 42 51 82.35%
contractcourt/htlc_outgoing_contest_resolver.go 15 26 57.69%
contractcourt/chain_arbitrator.go 1 14 7.14%
chainio/mocks.go 14 34 41.18%
contractcourt/htlc_incoming_contest_resolver.go 49 73 67.12%
lntest/harness_assertion.go 0 24 0.0%
contractcourt/channel_arbitrator.go 81 111 72.97%
Files with Coverage Reduction New Missed Lines %
contractcourt/anchor_resolver.go 1 78.2%
contractcourt/htlc_timeout_resolver.go 1 70.26%
queue/gc_queue.go 2 96.51%
invoices/invoiceregistry.go 2 82.26%
fn/send.go 2 66.67%
watchtower/wtclient/session_queue.go 2 82.92%
htlcswitch/mailbox.go 2 93.53%
watchtower/wtmock/peer.go 2 79.61%
htlcswitch/mock.go 2 75.25%
contractcourt/channel_arbitrator.go 4 75.14%
Totals Coverage Status
Change from base Build 9720833654: 0.02%
Covered Lines: 92854
Relevant Lines: 161978

💛 - Coveralls

@yyforyongyu yyforyongyu force-pushed the yy-blockbeat branch 3 times, most recently from d7ffa05 to 1db9b94 Compare July 2, 2024 12:47
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch from b4282fa to 6bb765f Compare July 4, 2024 12:12
@yyforyongyu yyforyongyu changed the base branch from yy-blockbeat to master July 9, 2024 18:36
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch 2 times, most recently from 691bb67 to 283e10f Compare July 10, 2024 18:11
yyforyongyu and others added 8 commits December 10, 2024 15:02
This `immediate` flag was added as a hack so during a restart, the
pending resolvers would offer the inputs to the sweeper and ask it to
sweep them immediately. This is no longer need due to `blockbeat`, as
now during restart, a block is always sent to all subsystems via the
flow `ChainArb` -> `ChannelArb` -> resolvers -> sweeper. Thus, when
there are pending inputs offered, they will be processed by the sweeper
immediately.
To avoid calling GetBestBlock again.
This is needed so the consumers have an initial state about the current
block.
In this commit we start to break up the starting process into smaller
pieces, which is needed in the following commit to initialize blockbeat
consumers.
Refactor the `Start` method to fix the linter error:
```
contractcourt/chain_arbitrator.go:568: Function 'Start' is too long (242 > 200) (funlen)
```
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch from a16b2d4 to ef85fb5 Compare December 10, 2024 07:05
We now put the outpoint in the resolvers's logging so it's easier to
debug.
This commit adds a few helper methods to decide how the htlc output
should be spent.
This commit is a pure refactor in which moves the sweep handling logic
into the new methods.
This commit refactors the `Resolve` method by adding two resolver
handlers to handle waiting for spending confirmations.
This commit adds new methods to handle making sweep requests based on
the spending path used by the outgoing htlc output.
This commit adds checkpoint methods in `htlcTimeoutResolver`, which are
similar to those used in `htlcSuccessResolver`.
This commit adds more methods to handle resolving the spending of the
output based on different spending paths.
We will use this and its following commits to break the original
`Resolve` methods into two parts - the first part is moved to a new
method `Launch`, which handles sending a sweep request to the sweeper.
The second part remains in `Resolve`, which is mainly waiting for a
spending tx.

Breach resolver currently doesn't do anything in its `Launch` since the
sweeping of justice outputs are not handled by the sweeper yet.
This commit breaks the `Resolve` into two parts - the first part is
moved into a `Launch` method that handles sending sweep requests, and
the second part remains in `Resolve` which handles waiting for the
spend. Since we are using both utxo nursery and sweeper at the same
time, to make sure this change doesn't break the existing behavior, we
implement the `Launch` as following,
- zero-fee htlc - handled by the sweeper
- direct output from the remote commit - handled by the sweeper
- legacy htlc - handled by the utxo nursery
This commit breaks the `Resolve` into two parts - the first part is
moved into a `Launch` method that handles sending sweep requests, and
the second part remains in `Resolve` which handles waiting for the
spend. Since we are using both utxo nursery and sweeper at the same
time, to make sure this change doesn't break the existing behavior, we
implement the `Launch` as following,
- zero-fee htlc - handled by the sweeper
- direct output from the remote commit - handled by the sweeper
- legacy htlc - handled by the utxo nursery
When calling `NotifyExitHopHtlc` it is allowed to pass a chan to
subscribe to the HTLC's resolution when it's settled. However, this
method will also return immediately if there's already a resolution,
which means it behaves like a notifier and a getter. If the caller
decides to only use the getter to do a non-blocking lookup, it can pass
a nil subscriber chan to bypass the notification.
A minor refactor is done to support implementing `Launch`.
This commit makes `resolved` an atomic bool to avoid data race. This
field is now defined in `contractResolverKit` to avoid code duplication.
In this commit, we break the old `launchResolvers` into two steps - step
one is to launch the resolvers synchronously, and step two is to
actually waiting for the resolvers to be resolved. This is critical as
in the following commit we will require the resolvers to be launched at
the same blockbeat when a force close event is sent by the chain watcher.
We need to offer the outgoing htlc one block earlier to make sure when
the expiry height hits, the sweeper will not miss sweeping it in the
same block. This also means the outgoing contest resolver now only does
one thing - watch for preimage spend till height expiry-1, which can
easily be moved into the timeout resolver instead in the future.
@yyforyongyu yyforyongyu force-pushed the yy-blockbeat-finalize branch from ef85fb5 to cebad6d Compare December 10, 2024 07:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants